Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.019

Text File | 1996-02-12 | 29KB | 583 lines

Frequently Asked Questions (FAQS);faqs.019



However, there are special cases for which scanning Unix systems for
non-Unix viruses does make sense.  For example, a Unix system which is
acting as a file server (e.g., PC-NFS) for PC systems is quite capable
of containing PC file infecting viruses that are a danger to PC clients.
Note that, in this example, the UNIX system would be scanned for PC
viruses, not UNIX viruses.

Another example is in the case of a 386/486 PC system running Unix,
since this system is still vulnerable to infection by MBR infectors
such as Stoned and Michelangelo, which are operating system
independent.  (Note that an infection on such a Unix PC system would
probably result in disabling the Unix disk partition(s) from booting.)

In addition, a file integrity checker (to detect unauthorized changes
in executable files) on Unix systems is a very good idea.  (One free
program which can do this test, as well as other tests, is the COPS
package, available by anonymous FTP on cert.org.)  Unauthorized
file changes on Unix systems are very common, although they usually
are not due to virus activity.


C8) Why does my anti-viral scanner report an infection only sometimes?

There are circumstances where part of a virus exists in RAM without
being active:  If your scanner reports a virus in memory only
occasionally, it could be due to the operating system buffering disk
reads, keeping disk contents that include a virus in memory
(harmlessly), in which case it should also find it on disk.  Or after
running another scanner, there may be scan strings left (again
harmlessly) in memory.  This is sometimes called a "ghost positive"
alert.


C9) Is my disk infected with the Stoned virus?

Of course the answer to this, and many similar questions, is to obtain
a good virus detector.  There are many to choose from, including ones
that will scan diskettes automatically as you use them.  Remember to
check all diskettes, even non-system ("data") diskettes.

It is possible, if you have an urgent need to check a system when
you don't have any anti-viral tools, to boot from a clean system
diskette, and use the CHKDSK method (mentioned in C1) to see if it is
in memory, then look at the boot sector with a disk editor.  Usually
the first few bytes will indicate the characteristic far jump of the
Stoned virus; however, you could be looking at a perfectly good disk
that has been "innoculated" against the virus, or at a diskette that
seems safe but contains a totally different type of virus.


C10) I think I have detected a new virus; what do I do?

Whenever there is doubt over a virus, you should obtain the latest
versions of several (not just one) major virus scanners. Some scanning
programs now use "heuristic" methods (F-PROT, CHECKOUT and SCANBOOT
are examples), and "activity monitoring" programs can report a disk or
file as being possibly infected when it is in fact perfectly safe
(odd, perhaps, but not infected).  If no string-matching scan finds a
virus, but a heuristic program does (or there are other reasons to
suspect the file, e.g., change in size of files) then it is possible
that you have found a new virus, although the chances are probably
greater that it is an odd-but-okay disk or file.  Start by looking in
recent VIRUS-L postings about "known" false positives, then contact
the author of the anti-virus software that reports it as virus-like;
the documentation for the software may have a section explaining what
to do if you think you have found a new virus.  Consider using the
BootID or Checkout programs to calculate the "hashcode" of a diskette
in the case of boot sector infectors, rather than send a complete
diskette or "live" virus until requested.


C11) CHKDSK reports 639K (or less) total memory on my system; am I
     infected?

If CHKDSK displays 639K for the total memory instead of 640K (655,360
bytes) - so that you are missing only 1K - then it is probably due to
reasons other than a virus since there are very few viruses which take
only 1K from total memory.  Legitimate reasons for a deficiency of 1K
include:

1) A PS/2 computer.  IBM PS/2 computers reserve 1K of conventional
  RAM for an Extended BIOS Data Area, i.e. for additional data storage
  required by its BIOS.
2) A computer with American Megatrends Inc. (AMI) BIOS, which is set
  up (with the built-in CMOS setup program) in such a way that the BIOS
  uses the upper 1K of memory for its internal variables.  (It can be
  instructed to use lower memory instead.)
3) A SCSI controller.
4) The DiskSecure program.
5) Mouse buffers for older Compaqs.

If, on the other hand, you are missing 2K or more from the 640K, 512K,
or whatever the conventional memory normally is for your PC, the
chances are greater that you have a boot-record virus (e.g. Stoned,
Michelangelo), although even in this case there may be legitimate
reasons for the missing memory:

1) Many access control programs for preventing booting from a floppy.
2) H/P Vectra computers.
3) Some special BIOSes which use memory (e.g.) for a built-in calendar
  and/or calculator.

However, these are only rough guides.  In order to be more certain
whether the missing memory is due to a virus, you should:
(1) run several virus detectors;
(2) look for a change in total memory every now and then;
(3) compare the total memory size with that obtained when cold booting
  from a "clean" system diskette.  The latter should show the normal
  amount of total memory for your configuration.

Note: in all cases, CHKDSK should be run without software such as
MS-Windows or DesqView loaded, since GUIs seem to be able to open DOS
boxes only on whole K boundaries (some seem to be even coarser); thus
CHKDSK run from a DOS box may report unrepresentative values.

Note also that some machines have only 512K or 256K instead of 640K of
conventional memory.


C12) I have an infinite loop of sub-directories on my hard drive; am I
     infected?

Probably not.  This happens now and then, when something sets the
"cluster number" field of some subdirectory the same cluster as an
upper-level (usually the root) directory.  The /F parameter of CHKDSK,
and any of various popular utility programs, should be able to fix
this, usually by removing the offending directory.  *Don't* erase any
of the "replicated" files in the odd directory, since that will erase
the "copy" in the root as well (it's really not a copy at all; just a
second pointer to the same file).


===================================
= Section D.    Protection plans  =
===================================

D1) What is the best protection policy for my computer?

There is no "best" anti-virus policy.  In particular, there is no
program that can magically protect you against all viruses.  But you
can design an anti-virus protection strategy based on multiple layers
of defense.  There are three main kinds of anti-viral software, plus
several other means of protection (such as hardware write-protect
methods).

1) GENERIC MONITORING programs.  These try to prevent viral activity
   before it happens, such as attempts to write to another executable,
   reformat the disk, etc.
   Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh).

2) SCANNERS.  Most look for known virus strings (byte sequences which
   occur in known viruses, but hopefully not in legitimate software) or
   patterns, but a few use heuristic techniques to recognize viral
   code.  A scanner may be designed to examine specified disks or
   files on demand, or it may be resident, examining each program
   which is about to be executed.  Most scanners also include virus
   removers.
   Examples: FindViru in Dr Solomon's Anti-Virus Toolkit, FRISK's
   F-Prot, McAfee's VIRUSCAN (all PC), Disinfectant (Macintosh).
   Resident scanners: McAfee's V-Shield, and VIRSTOP.
   Heuristic scanners: the Analyse module in FRISK's F-PROT package,
   and SCANBOOT.

3) INTEGRITY CHECKERS or MODIFICATION DETECTORS.  These compute a
   small "checksum" or "hash value" (usually CRC or cryptographic)
   for files when they are presumably uninfected, and later compare
   newly calculated values with the original ones to see if the files
   have been modified.  This catches unknown viruses as well as known
   ones and thus provides *generic* detection.  On the other hand,
   modifications can also be due to reasons other than viruses.
   Usually, it is up to the user to decide which modifications are
   intentional and which might be due to viruses, although a few
   products give the user help in making this decision.  As in the
   case of scanners, integrity checkers may be called to checksum
   entire disks or specified files on demand, or they may be resident,
   checking each program which is about to be executed (the latter is
   sometimes called an INTEGRITY SHELL).  A third implementation is as
   a SELF-TEST, i.e. the checksumming code is attached to each
   executable file so that it checks itself just before execution.
   Examples: Fred Cohen's ASP Integrity Toolkit (commercial), and
   Integrity Master and VDS (shareware), all for the PC.

3a) A few modification detectors come with GENERIC DISINFECTION.  I.e.,
   sufficient information is saved for each file that it can be
   restored to its original state in the case of the great majority
   of viral infections, even if the virus is unknown.
   Examples: V-Analyst 3 (BRM Technologies, Israel), marketed in the
   US as Untouchable (by Fifth Generation), and the VGUARD module of
   V-care.

Of course, only a few examples of each type have been given.  All of
them can find their place in the protection against computer viruses,
but you should appreciate the limitations of each method, along with
system-supplied security measures that may or may not be helpful in
defeating viruses.  Ideally, you would arrange a combination of
methods that cover the loopholes between them.

A typical PC installation might include a protection system on the
hard disk's MBR to protect against viruses at load time (ideally this
would be hardware or in BIOS, but software methods such as DiskSecure
and PanSoft's Immunise are pretty good).  This would be followed by
resident virus detectors loaded as part of the machine's startup
(CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+ and/or VirStop together
with ScanBoot.  A scanner such as F-Prot or McAfee's SCAN could be
put into AUTOEXEC.BAT to look for viruses as you start up, but this
may be a problem if you have a large disk to check (or don't reboot
often enough).  Most importantly, new files should be scanned as they
arrive on the system.  If your system has DR DOS installed, you should
use the PASSWORD command to write-protect all system executables and
utilities.  If you have Stacker or SuperStore, you can get some
improved security from these compressed drives, but also a risk that
those viruses stupid enough to directly write to the disk could do
much more damage than normal; using a software write-protect system
(such as provided with Disk Manager or Norton Utilities) may help, but
the best solution (if possible) is to put all executables on a disk of
their own, protected by a hardware read-only system that sounds an
alarm if a write is attempted.

If you do use a resident BSI detector or a scan-while-you-copy
detector, it is important to trace back any infected diskette to its
source; the reason why viruses survive so well is that usually you
cannot do this, because the infection is found long after the
infecting diskette has been forgotten with most people's lax scanning
policies.

Organizations should devise and implement a careful policy, that may
include a system of vetting new software brought into the building and
free virus detectors for home machines of employees/students/etc who
take work home with them.

Other anti-viral techniques include:
(a) Creation of a special MBR to make the hard disk inaccessible when
    booting from a diskette (the latter is useful since booting from a
    diskette will normally bypass the protection in the CONFIG.SYS and
    AUTOEXEC.BAT files of the hard disk).  Example: GUARD.
(b) Use of Artificial Intelligence to learn about new viruses and
    extract scan patterns for them.  Examples: V-Care (CSA Interprint,
    Israel; distributed in the U.S. by Sela Consultants Corp.), Victor
    Charlie (Bangkok Security Associates, Thailand; distributed in the
    US by Computer Security Associates).
(c) Encryption of files (with decryption before execution).


D2) Is it possible to protect a computer system with only software?

Not perfectly; however, software defenses can significantly reduce
your risk of being affected by viruses WHEN APPLIED APPROPRIATELY.
All virus defense systems are tools - each with their own capabilities
and limitations.  Learn how your system works and be sure to work
within its limitations.

From a software standpoint, a very high level of protection/detection
can be achieved with only software, using a layered approach.

1)  ROM BIOS - password (access control) and selection of boot disk.
    (Some may consider this hardware.)

2)  Boot sectors - integrity management and change detection.

3)  OS programs - integrity management of existing programs,
    scanning of unknown programs.  Requirement of authentication
    values for any new or transmitted software.

4)  Locks that prevent writing to a fixed or floppy disk.

As each layer is added, invasion without detection becomes more
difficult.  However complete protection against any possible attack
cannot be provided without dedicating the computer to pre-existing or
unique tasks.  The international standardization of the world on the
IBM PC architecture is both its greatest asset and its greatest
vulnerability.


D3) Is it possible to write-protect the hard disk with only software?

The answer is no.  There are several programs which claim to do that,
but *all* of them can be bypassed using only the currently known
techniques that are used by some viruses.  Therefore you should
never rely on such programs *alone*, although they can be useful in
combination with other anti-viral measures.


D4) What can be done with hardware protection?

Hardware protection can accomplish various things, including: write
protection for hard disk drives, memory protection, monitoring and
trapping unauthorized system calls, etc.  Again, no tool is foolproof.

The popular idea of write-protection (see D3) may stop viruses
spreading to the disk that is protected, but doesn't, in itself,
prevent a virus from running.

Also, some of the existing hardware protections can be easily
bypassed, fooled, or disconnected, if the virus writer knows them
well and designs a virus which is aware of the particular defense.


D5) Will setting DOS file attributes to READ ONLY protect them from
    viruses?

No.  While the Read Only attribute will protect your files from a few
viruses, most simply override it, and infect normally.  So, while
setting executable files to Read Only is not a bad idea, it is
certainly not a thorough protection against viruses!


D6) Will password/access control systems protect my files from
    viruses?

All password and other access control systems are designed to protect
the user's data from other users and/or their programs.  Remember,
however, that when you execute an infected program the virus in it
will gain your current rights/privileges.  Therefore, if the access
control system provides *you* the right to modify some files, it will
provide it to the virus too.  Note that this does not depend on the
operating system used - DOS, Unix, or whatever.  Therefore, an access
control system will protect your files from viruses no better than it
protects them from you.

Under DOS, there is no memory protection, so a virus could disable the
access control system in memory, or even patch the operating system
itself.  On the more advanced operating systems (Unix) this is not
possible, so at least the protection cannot be disabled by a virus.
However it will still spread, due to the reasons noted above.  In
general, the access control systems (if implemented correctly) are
able only to slow down the virus spread, not to eliminate viruses
entirely.

Of course, it's better to have access control than not to have it at
all.  Just be sure not to develop a false sense of security and to
rely *entirely* on the access control system to protect you.


D7) Will the protection systems in DR DOS work against viruses?

Partially.  Neither the password file/directory protection available
from DR DOS version 5 onwards, nor the secure disk partitions
introduced in DR DOS 6 are intended to combat viruses, but they do to
some extent.  If you have DR DOS, it is very wise to password-protect
your files (to stop accidental damage too), but don't depend on it as
the only means of defense.

The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM)
will stop more viruses than the plain DOS attribute facility, but that
isn't saying much!  The combination of the password system plus a disk
compression system may be more secure (because to bypass the password
system they must access the disk directly, but under SuperStore or
Stacker the physical disk is meaningless to the virus). There may be
some viruses which, rather than invisibly infecting files on
compressed disks in fact very visibly corrupt the disk.

The "secure disk partitions" system introduced with DR DOS 6 may be of
some help against a few viruses that look for DOS partitions on a
disk.  The main use is in stopping people fiddling with (and
infecting) your hard disk while you are away.

Furthermore, DR DOS is not very compatible with MS/PC-DOS, especially
down to the low-level tricks that some viruses are using.  For
instance, some internal memory structures are "read-only" in the sense
that they are constantly updated (for DOS compatibility) but not
really used by DR DOS, so that even if a sophisticated virus modifies
them, this does not have any effect.

In general, using a less compatible system diminishes the number of
viruses that can infect it.  For instance, the introduction of hard
disks made the Brain virus almost disappear; the introduction of 80286
and DOS 4.x+ made the Yale and Ping Pong viruses extinct, and so on.


D8) Will a write-protect tab on a floppy disk stop viruses?

In general, yes.  The write-protection on IBM PC (and compatible) and
Macintosh floppy disk drives is implemented in hardware, not software,
so viruses cannot infect a diskette when the write-protection mechanism
is functioning properly.

But remember:

(a) A computer may have a faulty write-protect system (this happens!)
    - you can test it by trying to copy a file to the diskette when it
    is presumably write-protected.
(b) Someone may have removed the tab for a while, allowing a virus on.
(c) The files may have been infected before the disk was protected.
    Even some diskettes "straight from the factory" have been known to be
    infected in the production processes.

So it is worthwhile scanning even write-protected disks for viruses.


D9) Do local area networks (LANs) help to stop viruses or do they
    facilitate their spread?

Both.  A set of computers connected in a well managed LAN, with
carefully established security settings, with minimal privileges for
each user, and without a transitive path of information flow between
the users (i.e., the objects writable by any of the users are not
readable by any of the others) is more virus-resistant than the same
set of computers if they are not interconnected.  The reason is that
when all computers have (read-only) access to a common pool of
executable programs, there is usually less need for diskette swapping
and software exchange between them, and therefore less ways through
which a virus could spread.

However, if the LAN is not well managed, with lax security, it could
help a virus to spread like wildfire.  It might even be impossible to
remove the infection without shutting down the entire LAN.

A network that supports login scripting is inherently more resistant
to viruses than one that does not, if this is used to validate the
client before allowing access to the network.


D10) What is the proper way to make backups?

Data and text files, and programs in source form, should be backed up
each time they are modified.  However, the only backups you should
keep of COM, EXE and other *executable* files are the *original*
versions, since if you back up an executable file on your hard disk
over and over, it may have become infected meanwhile, so that you may
no longer have an uninfected backup of that file.  Therefore:
  1. If you've downloaded shareware, copy it (preferably as a ZIP or
other original archive file) onto your backup medium and do not
re-back it up later.
  2. If you have purchased commercial software, it's best to create a
ZIP (or other) archive from the original diskettes (assuming they're
not copy protected) and transfer the archive onto that medium.  Again,
do not re-back up.
  3. If you write your own programs, back up only the latest version
of the *source* programs.  Depend on recompilation to reproduce the
executables.
  4. If an executable has been replaced by a new version, then of
course you will want to keep a backup of the new version.  However, if
it has been modified as a result of your having changed configuration
information, it seems safer *not* to back up the modified file; you
can always re-configure the backup copy later if you have to.
  5. Theoretically, source programs could be infected, but until such
a virus is discovered, it seems preferable to treat such files as
non-executables and back them up whenever you modify them.  The same
advice is probably appropriate for batch files as well, despite the
fact that a few batch file infectors have been discovered.


=======================================================
= Section E.    Facts and Fibs about computer viruses =
=======================================================

E1) Can boot sector viruses infect non-bootable floppy disks?

Any diskette that has been properly formatted contains an executable
program in the boot sector.  If the diskette is not "bootable," all
that boot sector does is print a message like "Non-system disk or disk
error; replace and strike any key when ready", but it's still
executable and still vulnerable to infection.  If you accidentally
turn your machine on with a "non-bootable" diskette in the drive, and
see that message, it means that any boot virus that may have been on
that diskette *has* run, and has had the chance to infect your hard
drive, or whatever.  So when thinking about viruses, the word
"bootable" (or "non-bootable") is really misleading.  All formatted
diskettes are capable of carrying a virus.


E2) Can a virus hide in a PC's CMOS memory?

No.  The CMOS RAM in which system information is stored and backed up
by batteries is ported, not addressable.  That is, in order to get
anything out, you use I/O instructions.  So anything stored there is
not directly sitting in memory.  Nothing in a normal machine loads the
data from there and executes it, so a virus that "hid" in the CMOS RAM
would still have to infect an executable object of some kind in order
to load and execute whatever it had written to CMOS.  A malicious
virus can of course *alter* values in the CMOS as part of its payload,
but it can't spread through, or hide itself in, the CMOS.

A virus could also use the CMOS RAM to hide a small part of its
body (e.g., the payload, counters, etc.).  However, any executable
code stored there must be first extracted to ordinary memory in order
to be executed.


E3) Can a virus hide in Extended or in Expanded RAM?

Theoretically yes, although no such viruses are known yet.  However,
even if they are created, they will have to have a small part resident
in conventional RAM; they cannot reside *entirely* in Extended or in
Expanded RAM.


E4) Can a virus hide in Upper Memory or in High Memory?

Yes, it is possible to construct a virus which will locate itself
in Upper Memory (640K to 1024K) or in High Memory (1024K to 1088K),
and a few currently known viruses (e.g. EDV) do hide in Upper Memory.

It might be thought that there is no point in scanning in these areas
for any viruses other than those which are specifically known to
inhabit them.  However, there are cases when even ordinary viruses can
be found in Upper Memory.  Suppose that a conventional memory-resident
virus infects a TSR program and this program is loaded high by the
user (for instance, from AUTOEXEC.BAT).  Then the virus code will also
reside in Upper Memory.  Therefore, an effective scanner must be able
to scan this part of memory for viruses too.


E5) Can a virus infect data files?

Some viruses (e.g., Frodo, Cinderella) modify non-executable files.
However, in order to spread, the virus must be executed.  Therefore
the "infected" non-executable files cannot be sources of further
infection.

However, note that it is not always possible to make a sharp
distinction between executable and non-executable files.  One man's
code is another man's data and vice versa.  Some files that are not
directly executable contain code or data which can under some
conditions be executed or interpreted.

Some examples from the IBM PC world are .OBJ files, libraries, device
drivers, source files for any compiler or interpreter, macro files
for some packages like MS Word and Lotus 1-2-3, and many others.
Currently there are viruses that infect boot sectors, master boot
records, COM files, EXE files, BAT files, and device drivers, although
any of the objects mentioned above can theoretically be used as an
infection carrier.  PostScript files can also be used to carry a virus,
although no currently known virus does that.


E6) Can viruses spread from one type of computer to another?

The simple answer is that no currently known viruses can do this.
Although the disk formats may be the same (e.g. Atari ST and DOS), the
different machines interpret the code differently.  For example, the
Stoned virus cannot infect an Atari ST as the ST cannot execute the
virus code in the bootsector.  The Stoned virus contains instructions
for the 80x86 family of CPU's that the 680x0-family CPU (Atari ST)
can't understand or execute.

The more general answer is that such viruses are possible, but
unlikely.  Such a virus would be quite a bit larger than current
viruses and might well be easier to find.  Additionally, the low
incidence of cross-machine sharing of software means that any such
virus would be unlikely to spread -- it would be a poor environment
for virus growth.


E7) Can DOS viruses run on non-DOS machines (e.g. Mac, Amiga)?

In general, no.  However, on machines running DOS emulators (either
hardware or software based), DOS viruses - just like any DOS program -
may function.  These viruses would be subject to the file access
controls of the host operating system.  An example is when running a
DOS emulator such as VP/ix under a 386 UNIX environment, DOS
programs are not permitted access to files which the host UNIX system
does not allow them to.  Thus, it is important to administer these
systems carefully.


E8) Can mainframe computers be susceptible to computer viruses?

Yes.  Numerous experiments have shown that computer viruses spread
very quickly and effectively on mainframe systems.  However, to our
knowledge, no non-research computer virus has been seen on mainframe
systems.  (The Internet worm of November 1988 was not a computer virus
by most definitions, although it had some virus-like characteristics.)

Computer viruses are actually a special case of something else called
"malicious logic", and other forms of malicious logic -- notably
Trojan horses -- are far quicker, more effective, and harder to detect
than computer viruses.  Nevertheless, on personal computers many more
viruses are written than Trojans.  There are two reasons for this:
(1) Since a virus propagates, the number of users to which damage can
be caused is much greater than in the case of a Trojan; (2) It's
almost impossible to trace the source of a virus since viruses are
not attached to any particular program.

For further information on malicious programs on multi-user systems,
see Matt Bishop's paper, "An Overview of Malicious Logic in a Research
Environment", available by anonymous FTP on Dartmouth.edu
(129.170.16.4) as "pub/security/mallogic.ps".